@hzrd149 fyi. 🫡

I am resultant to introduce any kind of metadata document for individual servers. I'm sure it will be useful for describing a single server, but having a "information document" or "site map" can introduce an additional step when interacting with servers. and it opens up the possibility for servers to start acting differently (besides rejecting types of uploads)

For example if it became standard for servers to have an /information endpoint (or /.well-known) it wouldn't be a stretch for that document to contain a "downloadURL" field that should be used to download blobs from, or a "uploadApiEndpoint" field that changed the standard upload endpoint

Again not that big of a deal for a single server, but if the client/user needs to intact with multiple servers it becomes a very complicated process just to upload a blob since it would have to check all requirements for every server

For a good example of this look at the /.well-known/nostr/nip96.json document in NIP-96. IMO its way to customizable, which made it really difficult for users and clients to interact with the services

this standard wouldn't contain uploadapiendpoint or downloadURL and similar stuff. it would just help client to understand what they are dealing with. how to contact them? what is their name? do they respect reports at all? or they are a dark web like thing? its paid or not? is it possible for media to be removed in future or not? and more.

this standard wouldn't contain uploadapiendpoint or downloadURL and similar stuff. it would just help client to understand what they are dealing with. how to contact them? what is their name? do they respect reports at all? or they are a dark web like thing? its paid or not? is it possible for media to be removed in future or not? and more.

Most of this can either be expressed in HTTP headers or on the servers homepage for users to read. I want to avoid is clients changing their behavior based on what server they are talking to.
Once clients start treating every server differently then we start to loose the simple interoperability between servers. again NIP-96 and NIP-11 are good examples of this. very few clients pay attention to or implement them because there is so much customization and restrictions to take into account

If the goal is to inform the user about how the server works ( upload limitations, accepted mime types, .onion urls, etc ) I think it would be a lot better to show that on the servers homepage instead of a json document that would rely on the client to support

@hzrd149 these are logical reasons as well.

@v0l @quentintaranpino @pablof7z what do you guys think?

I agree with both of the points you made, this can be useful as long as it doesn't change any of the existing buds

it won't break or change anything.

should we close this?

should we close this?

No i dont think so, why would you close it?

@v0l if it doesn't make sense and won't get implemented so its pointless.
but i think we need more discussion on it.

@v0l if it doesn't make sense and won't get implemented so its pointless. but i think we need more discussion on it.

If you close the issue it certainly will never be implemented :D

Try to get other server/client devs to give feedback

I would like at least pubkey information because I want to make a zap. Assuming that kind-0 is published for the pubkey.

@v0l if it doesn't make sense and won't get implemented so its pointless. but i think we need more discussion on it.

If you close the issue it certainly will never be implemented :D

Try to get other server/client devs to give feedback

@v0l makes sense. i've mentioned them before, waiting for them to respond.

I would like at least pubkey information because I want to make a zap. Assuming that kind-0 is published for the pubkey.

of course, it would be possible. and basically a pubkey with kind-0 published is expected most of the time.

it even enables tools like nostr watch to discover blossom servers as well and a lot more. currently they are just black boxes.

ACK.

I would like to have a machine readable file that gives some basic info about the server. For my use case, I'm principally interested in whether the server requires auth for the various standard endpoints.

This makes it much easier for my app to allow users to specify what blossom server they want to use and for the app to check that that blossom server conforms to the things we need; in White Noise's case, that the GET /<sha256> endpoint doesn't require auth.

I would like to have a machine readable file that gives some basic info about the server. For my use case, I'm principally interested in whether the server requires auth for the various standard endpoints.

For individual actions like a specific upload for downloading a specific blob, the HEAD method can be used to check for 401
Although I agree there is a use case for servers to describe their general auth / upload / retention policies

Yeah, it's easy enough to check on a case by case basis, if you have a file. But we want to know that group members will be able to download files without auth before we allow a user to set a specific blossom server they want to use. Otherwise it's pointless to allow the user to select it. So in this case (when we don't have a file url) we need to have another way to check, otherwise we'll have to upload trash to the server, then use the HEAD method to check for the presence of auth on the GET endpoint.

@hzrd149 @erskingardner that's correct. using such a documentt is the most proper way for both users and machines to understand these stuff. basiccly we have a lot of usecases for this and also it won't break/change anything in protocol.

I'm partially in favor of adding this. However, I think we should first reach a broader consensus about exactly what kind of information we want to include here. It might be beneficial to give this proposal a bit more time to mature before finalizing it.

@quentintaranpino yes, fields can change. i believe cashu paid storage information can be added here.

if we get implementations, we can finalize the fields based on people implementations.

Can we maybe build this externally first, like an extended version of blossomserver.com (https://github.com/hzrd149/blossomservers) --> like caniuse.com?

IMHO it would make sense to expore what data is needed, for example I would like to know supports_range_requests, max_upload_size, etc.

For server discovery ( users choosing a blossom server ) I think it makes more sense to build that externally with nostr or a transitional website. blossom servers having a descriptive home pages can help with this

For things like range request support or /mirror support. those can easily be checked with a HEAD request. but there are a few things like "max upload size", "accepted mime types", and "expiration time" that cant easily be exposed using http headers

this bud is not only for discovery. it has a lot of use cases that different apps and clients need.

http headers can't cover all needs.

this bud is not only for discovery. it has a lot of use cases that different apps and clients need.

This is what I'm worried about in a way. If we describe how blossom servers behave in a machine readable way then clients will start being developed against that and automatically selecting blossom servers without asking the user.

I don't think blossom successes if clients automatically select upload servers for the user and "hide" the complexity from the user.
The powerful part about blossom is that its not just a generic uploading solution, instead its a way for users to bring their own public storage servers to a client app

However having some information about the servers rules / policies is necessary to allow users to pick servers. but I'm undecided how much of that should be described on the servers homepage (In human readable format) or in a machine readable file
A good example of a homepage is https://24242.io/ it allows users to quickly get an idea of how the server works and what the user could use the server for

P.S. Sorry I've been ignoring this PR and thread for a while, I've been busy and I don't think we should rush something like this

I don't think blossom successes if clients automatically select upload servers for the user and "hide" the complexity from the user.

I'm very sympathetic to this. That said, I think machine readable capabilities gives clients the ability to build some safeguards to help users select blossom servers that do support the features that they need in order to function properly. There's no point in giving a user choice, then allowing them to select a server that isn't going to work. Or, only slightly less bad, giving the user loads of required tech specs and then hoping that they'll work out what blossom server might be compatible.

its now planned on nos3 blossom server to be implemented: dezh-tech/nos3#20

also, more users are demanding this: #66

which means it's needed...

@hzrd149 thank you for your suggestions. ive just updated the spec. i kept icons and supported buds since they won't break anything, and they are just information. but i removed the limitations part.

This spec uses the exact same names as NIP-11, which is good.

I think this is an important addition to the spec, allowing both system administrators and users to get a minimum set of metadata from the media server. The uploading_policy is an important aspect.

I think Primal just upgraded their Blossom server and now my Nostr app doesn't work anymore, I have no idea what software they might be running, what policy has changed, etc? It just returns errors when I attempt to list my files. At least as a technical person, I could mitigate it if there is upgraded to servers, different implementations incompatibilities, etc. Without any info, I'm stuck with asking the admins... and who are users supposed to contact, if there is no BUD-12 information to begin with?

It will be abused; I am planning on abusing this with some extra fields. That's not a good reason to don't include this though, that is the nature of anything.

👍

@sondreb thank you for explaining this. you can add extra fields to bud12 documents as well. also, we hace contact information on current standard.

update:

khatru implementation:

• feat(blossom): supporting bud-12. fiatjaf/khatru#48

NIP-11 was a mistake, and this will be also. Please don't merge.

@fiatjaf

why?

also, we can see enough use-cases and developer requests for this.

NIP-11 was a mistake, and this will be also. Please don't merge.

Strong opinions need strong reasons. :) Why was NIP-11 a mistake and why would this be?

NIP-11 was a mistake, and this will be also. Please don't merge.

What matters is the need and purpose. I have a purpose for NIP-11 and that is showing nicely formatted information about the relays to user's. Additionally there are multiple NIPs afaik that explicitly says to not post event kinds to relays unless they specifically support certain NIPs. How are Nostr clients suppose to figure this out, without NIP-11?

There are two ways to connect with servers, either through protocol/software versioning, or capability-discovery. If there is no NIP-11, it means clients need to poke and query what features the relays actually supports. It is obviously a horrible idea to have the clients attempt various features to see if it works, so either NIP-11 or the relays should send capabilities (and metadata) in a reply to a REQ.

Clients needs to be informed about NIPs supported by the relays. For this purpose, NIP-11 is not a mistake, it's the only source for this information that is reliable. Perhaps relays have started returning NIP-11 metadata over WebSocket now that I don't know about to replace this capability of NIP-11?

This makes sense if it stays strictly descriptive and optional. Basic metadata like name, contact, pubkey, etc. Useful for tools and users. No behavior, no endpoints, no client-side logic should depend on it.

Dropping the limitations part was the right call. If this turns into another NIP11 full of optional complexity, it will get ignored. Keep it minimal and factual IMHO.

It will be abused; I am planning on abusing this with some extra fields. That's not a good reason to don't include this though, that is the nature of anything.

There are two ways to connect with servers, either through protocol/software versioning, or capability-discovery. If there is no NIP-11, it means clients need to poke and query what features the relays actually supports. It is obviously a horrible idea to have the clients attempt various features to see if it works, so either NIP-11 or the relays should send capabilities (and metadata) in a reply to a REQ.

This makes sense, but its something I want to avoid. ideally blossom servers and the blossom protocol can be simple enough to where it does not need to be "negotiated" between clients and servers.

Maybe some negotiation or discovery is necessary for clients to understand how they can or should upload to servers. i.e. does it support /media, can I upload this mime type, etc... but I don't think negotiation or discovery helps at all for downloading blobs.
In fact it think it hurts the censorship resistance of the protocol if clients need to figure out how they can download from a server before connecting to it.

This is what I'm hung up on, I understand the arguments for having a simple information document (name, icon, metadata, upload policy, contact info, etc) but I'm worried about the protocol fracturing or becoming more complex if servers start to introduce extra metadata field that clients start to rely on before connecting to the server

NIP-11 was a mistake, and this will be also. Please don't merge.

I generally agree with @fiatjaf that NIP-11 was a mistake. It was convent to have the owners pubkey and contact info, but from my experience the limitations and other fields that describe how a relay operates make things very complicated for clients, so much so they tend to ignore them (at least all the clients I've seen do)

and again I apologize for ignoring these conversations for weeks. I need to start setting more time aside to maintaining this repo

@hzrd149

I generally agree with @fiatjaf that NIP-11 was a mistake. It was convent to have the owners pubkey and contact info, but from my experience the limitations and other fields that describe how a relay operates make things very complicated for clients, so much so they tend to ignore them (at least all the clients I've seen do)

The limitations is already removed...

When a user adds a relay or media server, they could (should?) be presented with the policies that apply. I want users to explicitly accept agreements and policies for relays and media servers. Doing implicit agreements is relying on the State.

@erskingardner

Strong opinions need strong reasons. :) Why was NIP-11 a mistake and why would this be?

NIP-11 is only useful for providing a name, an icon and a description for the relay, and a public key. But because the relay name should be its domain name and the relay icon should be /favicon.ico and the description isn't very useful anyway the only added benefit of NIP-11 is the public key, which might be useful in some rare cases, and we might have provided that in a more efficient way regardless.

@quentintaranpino

This makes sense if it stays strictly descriptive and optional. Basic metadata like name, contact, pubkey, etc. Useful for tools and users. No behavior, no endpoints, no client-side logic should depend on it.

Maybe these things are mildly useful for relays, but for media servers? They're barely useful and more likely to be harmful (names allow impersonation while DNS doesn't, for example). Also media servers are much more likely to remain commoditized than Nostr relays, so their identity should matter much less.

@sondreb

When a user adds a relay or media server, they could (should?) be presented with the policies that apply. I want users to explicitly accept agreements and policies for relays and media servers.

A standardized JSON object will never be enough for an agreement. Users should either know the terms because someone told them or they memorized or they should go to the media server website and read what is to be read there.

Doing implicit agreements is relying on the State.

I'm interested. Why? I don't think there is an implicit agreement when you just upload a file to a server you don't know at all. You just uploaded the file, no one has agreed on anything. What has the State to do with it?

I believe in a contract society, where everything is based on voluntary agreements, no implicit rules mandates by a third party.

When I provide a service, I want to give information and receive consent from the receiver/user of the service.

It can of course be enough to simply redirect the users to the website of the media server and have them find agreements there.

If there are no implicit contract behind the media server, meaning they (the service provider) don't care about the State, it means anyone is allowed to upload anything to those media servers. This is obviously not the case, most people who host these media servers want their users to follow certain rules and many rely on the implicit support of the State. That's a whole different discussion though, if this JSON endpoint don't get added it's fine, I'll send user's to the websites.

@kehiy The BUD looks better without the limitations JSON and I still like the idea of exposing a link to the uploading policy and the software/version. however as @fiatjaf mentioned, having server names set from a JSON document instead of domain name opens up the possibility for impersonation

Impersonation may be an issue because users could start referring to (and searching for) servers based on the name instead of domain, in which case it would be easy for bad actors to spin up 100+ servers with the same names as popular servers

Also for the uploading policy URL, there may be some small use for having it available in a JSON document, wouldn't most servers have this in big bold text on their home page?

@hzrd149 Users/clients must take care of their security by following best practices, I believe. For the privacy policy link, without BUD-12, they can put it on their home page as well. Like a big text or in their website footer/header. I use both NIP-11 and manual documents on the website for my relay.

I still prefer to keep such things in the standard, but the rest of the decision is up to other devs and users here. I keep an eye on that.

Any updated on this?